15. 보안의 기본과 개념2

78. SSL/TLS

암호화 통신을 수행하는 절차를 규정한 프로토콜

개념:
공개키 암호화 방식을 이용하여 연결 대상의 정당성을 확인한 후 암호화 통신에 필요한 키를 생성하고, 패킷 암호화와 복호화를 실행함

SSL을 개량하여 TLS를 설계함

역사적 발전:

SSL/TLS 발전 과정:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[SSL (Secure Sockets Layer)]
    ↓
브라우저 개발사가 개발
    ↓
HTTPS에 암호화 적용
    ↓

[IETF 표준화]
    ↓
[TLS (Transport Layer Security)]
    ↓
인터넷 표준으로 재설계

→ SSL과 TLS 1.1 이전: 취약점 발견
→ TLS 1.2, TLS 1.3: 정식 프로토콜

프로토콜 배경:

SSL과 TLS는 모두 웹 브라우저와 웹 서버 간 통신을 암호화하는 프로토콜
HTTPS 프로토콜에는 암호화를 위한 상세한 절차를 규정하지 않아 웹 브라우저에 구현된 SSL 프로토콜이 사용됨
SSL은 웹 브라우저 개발사에서 만든 프로토콜이었기 때문에 인터넷 기술 표준화 단체인 IETF가 TLS로 다시 설계하여 인터넷 표준으로 삼음

호환성:

TLS는 SSL을 계승하여 설계되었지만 둘 사이에 엄격한 호환성은 없음
이후 SSL과 TLS 1.1 이전의 프로토콜에 취약성이 발견됨
TLS 1.2와 1.3이 정식 프로토콜

TLS 핸드셰이크 - 상세 과정

TLS 핸드셰이크란?

TLS 통신을 시작하기 전에 클라이언트와 서버가 서로 인증하고 암호화 방식을 협상하며, 안전하게 세션 키를 교환하는 과정

TLS 핸드셰이크 전체 과정:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[클라이언트]                           [서버]
     |                                    |
     |--① ClientHello----------------→|
     |   • 지원하는 TLS 버전             |
     |   • 지원하는 암호화 알고리즘        |
     |   • 랜덤 데이터 (난수 1)          |
     |                                    |
     |←-② ServerHello------------------|
     |   • 선택한 TLS 버전               |
     |   • 선택한 암호화 알고리즘          |
     |   • 랜덤 데이터 (난수 2)          |
     |                                    |
     |←-③ Certificate------------------|
     |   • 서버 인증서                   |
     |   • 서버 공개키 포함               |
     |                                    |
     |←-④ ServerHelloDone--------------|
     |   • 서버 메시지 전송 완료          |
     |                                    |
     ↓                                    |
[인증서 검증]                            |
 • CA 서명 확인                          |
 • 유효 기간 확인                         |
 • 도메인 일치 확인                       |
     |                                    |
     |--⑤ ClientKeyExchange----------→|
     |   • Pre-Master Secret 생성       |
     |   • 서버 공개키로 암호화           |
     |                                    |
     |                                    ↓
     |                          [개인키로 복호화]
     |                          [Pre-Master Secret 획득]
     |                                    |
     ↓                                    ↓
[세션 키 생성]                    [세션 키 생성]
 • 난수 1 + 난수 2                • 난수 1 + 난수 2
   + Pre-Master Secret              + Pre-Master Secret
 → Master Secret                  → Master Secret
 → 세션 키 (대칭키)                → 세션 키 (대칭키)
     |                                    |
     |--⑥ ChangeCipherSpec-----------→|
     |   "이제부터 암호화 통신 시작"       |
     |                                    |
     |--⑦ Finished-------------------→|
     |   (암호화된 핸드셰이크 완료 메시지)  |
     |                                    |
     |←-⑧ ChangeCipherSpec-------------|
     |   "OK, 암호화 통신 시작"           |
     |                                    |
     |←-⑨ Finished---------------------|
     |   (암호화된 핸드셰이크 완료 메시지)  |
     |                                    |
     |←======암호화 통신 시작========→|

인증서 검증 과정

클라이언트가 수행하는 검증:

서버 인증서 검증 단계:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[서버 인증서 수신]
    ↓
1. [CA 서명 검증]
   ↓
   브라우저에 내장된 신뢰할 수 있는
   CA(인증 기관) 리스트 확인
   ↓
   CA의 공개키로 인증서 서명 검증
   ↓
   서명이 유효한가? ✓

2. [유효 기간 확인]
   ↓
   현재 날짜가 인증서 유효 기간 내인가?
   ↓
   2024-01-01 ~ 2025-12-31 ✓

3. [도메인 일치 확인]
   ↓
   접속하려는 도메인과 인증서의 도메인이 같은가?
   ↓
   URL: https://example.com
   인증서: CN=example.com ✓

4. [폐기 여부 확인]
   ↓
   CRL 또는 OCSP로 인증서 폐기 여부 확인
   ↓
   폐기되지 않음 ✓

→ 모든 검증 통과 시 인증서 유효

하이브리드 암호화 시스템

TLS가 두 가지 암호화 방식을 조합하는 이유:

암호화 방식별 장단점:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[공개키 암호화 (RSA, ECC)]
장점: ✓ 키 교환 안전
단점: ✗ 속도 매우 느림 (1000배 이상)
용도: 세션 키 교환에만 사용

[대칭키 암호화 (AES)]
장점: ✓ 속도 매우 빠름
단점: ✗ 키 교환 어려움
용도: 실제 데이터 암호화에 사용

HTTPS 통신의 하이브리드 방식:

하이브리드 암호화 흐름:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1단계: 핸드셰이크 (공개키 암호화)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[클라이언트]
    ↓
Pre-Master Secret 생성 (랜덤 값)
    ↓
[서버 공개키(RSA)로 암호화]
    ↓
암호화된 Pre-Master Secret 전송
    ↓

[서버]
    ↓
[서버 개인키(RSA)로 복호화]
    ↓
Pre-Master Secret 획득

→ 양쪽 모두 Pre-Master Secret 보유
→ 같은 알고리즘으로 세션 키(AES) 생성


2단계: 데이터 전송 (대칭키 암호화)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[클라이언트] → 데이터를 AES로 암호화 → [서버]
[클라이언트] ← 데이터를 AES로 암호화 ← [서버]

→ 빠른 속도로 대용량 데이터 전송 가능

실제 통신 예시:

HTTPS 요청/응답 과정:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[1] 핸드셰이크 완료 (0.2초)
    └─ RSA로 세션 키 교환

[2] HTTP 요청 (0.01초)
    ↓
GET /index.html HTTP/1.1
Host: example.com
    ↓
[AES-256으로 암호화]
    ↓
암호화된 패킷 전송

[3] HTTP 응답 (0.5초)
    ↓
HTML 파일 (100KB)
    ↓
[AES-256으로 암호화]
    ↓
암호화된 패킷 전송

→ 핸드셰이크는 느리지만 한 번만
→ 데이터 전송은 빠른 AES 사용

세션 키 생성 메커니즘

양쪽이 같은 키를 생성하는 방법:

세션 키 생성 과정:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[클라이언트]                    [서버]
     |                            |
클라이언트 랜덤                서버 랜덤
"abc123..."                   "xyz789..."
     |                            |
     +------Pre-Master Secret-----+
           (암호화 전송)
              "pms456..."
     |                            |
     ↓                            ↓
Master Secret 생성:
SHA-256(
  클라이언트 랜덤 +
  서버 랜덤 +
  Pre-Master Secret
)
     |                            |
     ↓                            ↓
"master789..."              "master789..."
     |                            |
     ↓                            ↓
세션 키 생성:
  • 암호화 키 (클라이언트→서버)
  • 암호화 키 (서버→클라이언트)
  • MAC 키 (무결성 검증용)
     |                            |
     ↓                            ↓
동일한 세션 키 세트 보유!

보안 특징:

세션 키 보안성:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[Perfect Forward Secrecy]
  └─ 각 세션마다 새로운 세션 키 생성
     └─ 이전 세션 기록 노출되어도
        다른 세션은 안전

[랜덤성]
  └─ 클라이언트 랜덤 + 서버 랜덤 사용
     └─ 예측 불가능한 키 생성

[키 노출 방지]
  └─ 세션 키 자체는 네트워크로 전송 안 됨
     └─ 재료만 교환하여 양쪽에서 생성

TLS 통신의 보안 효과

보안 효과:

TLS 암호화 통신의 보안:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[암호화된 데이터]
    ↓
네트워크 상의 기기로 전송
    ↓

보호 대상:
  ✓ 도청 방지
    └─ 중간 라우터가 내용 볼 수 없음

  ✓ 사칭 방지
    └─ 서버 인증서로 신원 확인

  ✓ 변조 방지
    └─ MAC (Message Authentication Code)으로 무결성 검증

→ 안전한 데이터 전송 보장

실제 네트워크에서의 보호:

중간 라우터의 관점:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[라우터가 볼 수 있는 것]
  • 출발지 IP: 192.168.1.100
  • 목적지 IP: 93.184.216.34
  • 프로토콜: HTTPS (443 포트)

[라우터가 볼 수 없는 것]
  • 실제 URL 경로
  • 전송되는 데이터 내용
  • 쿠키, 로그인 정보
  • HTTP 헤더 상세 내용

→ 경로는 알지만 내용은 모름

79. 방화벽

네트워크 세그먼트 경계에 설치되는 게이트웨이의 일종

주된 역할:
외부에서 들어오는 불필요한 패킷이나 수상한 접속 등을 차단하는 것

보안 대책의 기본이 되는 방화벽

방화벽의 위치:

네트워크 보안 구조:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[인터넷]
    ↓
[엣지 라우터]
    ↓
[방화벽] ← 경계에 설치
    ↓
[내부 LAN]

기본 개념:

네트워크 보안 대책의 가장 기본적인 구조 중 하나
일반적으로 인터넷과 LAN의 경계인 엣지 라우터 바로 뒤에 설치

동작 원리:

구분	라우터	방화벽
확인 항목	IP 주소	IP 주소, 포트 번호, 패킷 내용
판단 기준	자신의 LAN으로 전송 여부	통과 허용 여부
처리	전송/차단	허용/차단

통합 제품:

실제 라우터에는 방화벽 기능이 탑재된 제품도 있음

방화벽 종류

분류 기준:

방화벽은 패킷을 체크하는 정도나 방법에 따라 패킷 필터링형과 게이트웨이형으로 분류

방화벽 분류:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[패킷 필터링형]
  └─ IP 주소, 포트 번호 기준
     └─ 통과시킬 패킷 제어

[게이트웨이형 (프록시형)]
  └─ 모든 통신 제어
     └─ 창구 역할

패킷 필터링형 세부 분류:

패킷 필터링형 종류:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[스태틱형 (Static)]
  └─ 고정 리스트 관리
     └─ IP 주소/포트 고정

[다이내믹형 (Dynamic)]
  └─ 동적 리스트
     └─ 응답 패킷 허용 등

[스테이트풀형 (Stateful)]
  └─ 프로토콜 순서 감시
     └─ 부정한 액세스 차단

각 유형별 특징:

스태틱형: 차단하거나 통과시킬 IP 주소나 포트를 고정 리스트로 관리
다이내믹형: 특정 통신에 대한 응답이면 허용하는 등 동적인 리스트
스테이트풀형: 패킷 단독이 아니라 프로토콜 순서도 감시하여 부정한 액세스를 차단

프록시형 방화벽

프록시 개념:

프록시란 인터넷과 LAN 경계에서 패킷 출입을 대행해서 처리하는 기능을 의미

프록시 서버 역할:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[내부 네트워크]
       |
       ↓
  [프록시 서버]
       |
    대행 처리
       ↓
   [인터넷]

기능:
  • 패킷 제어
  • 액세스 부하 분산
  • 보안 대책

활용 목적:

패킷 제어
액세스 부하의 분산
보안 대책

네트워크 내부와 외부 모두 방화벽이 창구 역할을 하기 때문에 프록시형이라고도 함

GFW (Great Firewall)

국가 단위 방화벽:

방화벽은 일반적으로 인터넷과 기업이나 조직의 인트라넷 경계에 설치함. 이 개념을 국경까지 확장한 것이 중국의 GFW(Great FireWall)임

GFW 동작 원리:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[중국 국내] ←─── GFW ───→ [국외 인터넷]
                |
            차단 대상:
              • 금지 웹사이트 IP
              • 차단 URL
              • 특정 키워드

기능:

중국 국내외를 오가는 통신 제어
중국 정부가 금지한 웹 사이트에서 오는 통신 차단
금지된 웹 사이트로 연결하는 통신 차단
IP주소나 URL 등으로 차단

80. DMZ

DMZ = Demilitarized Zone (비무장지대)

외부 네트워크와 내부 네트워크 사이에 설치하는 네트워크 상의 세그먼트

목적:
외부 액세스가 필요한 서버와 외부에 공개하지 않는 내부 네트워크를 모두 보호

공개 서버와 내부 네트워크 보호

DMZ 개념:

DMZ 네트워크 구조:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[인터넷]
    ↓
[엣지 라우터]
    ↓
[방화벽 1]
    ↓
[DMZ 세그먼트]
├─ 웹 서버
├─ 메일 서버
└─ DNS 서버
    ↓
[방화벽 2]
    ↓
[내부 네트워크]
└─ 중요 데이터

정의:

DMZ란 내부 네트워크를 외부 공격에서 보호하려고 방화벽 등으로 격리한 네트워크 상의 세그먼트. 일반적으로는 외부에 공개하는 웹서버나 메일 서버 등을 배치함

보안 문제:

DMZ 필요성:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[웹 서버를 내부에 배치]
    ↓
인터넷에서 접속 허용 필요
    ↓
외부 패킷이 내부까지 도달
    ↓
보안 위험 증가
    ↓

[해결: DMZ 구성]
    ↓
웹 서버를 DMZ에 격리
    ↓
내부 네트워크 2단계 보호

보호 메커니즘:

웹 서버는 웹 사이트를 인터넷에 공개할 때 인터넷을 통해 웹 서버에 액세스할 수 있게 함
웹 서버는 에지 라우터보다 안쪽 세그먼트에 두게 되는데, 외부에서 오는 무작위 패킷이 내부까지 도달하는 것은 보안상 위험 요소가 됨
웹 서버를 배치한 세그먼트를 방화벽 등으로 격리해서 내부 네트워크를 보호
DMZ는 외부에 직접 공개하지 않는 내부 네트워크를 2단계로 보호하는 세그먼트

라우터 등을 활용한 DMZ의 다양화

유연한 구성:

실제 네트워크에서는 DMZ 앞뒤로 방화벽을 배치하기도 함

다양한 DMZ 구성:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

구성 1: 단일 방화벽
[인터넷] → [방화벽(DMZ 기능)] → [내부]

구성 2: 이중 방화벽
[인터넷] → [방화벽1] → [DMZ] → [방화벽2] → [내부]

구성 3: 라우터 통합
[인터넷] → [라우터+방화벽+DMZ] → [내부]

제품 특징:

라우터 제품에는 다음과 같은 기능을 갖춘 제품이 있어 유연하게 DMZ 환경을 구축할 수 있음:

방화벽 기능을 갖춘 제품
DMZ 설정 기능을 갖춘 제품

네트워크 장비의 본질:

라우터, 게이트웨이, 방화벽은 네트워크 장비로서 개별 하드웨어로 되어있을 때가 많지만, 이들 장비의 내부는 서버와 차이가 없음

네트워크 장비 내부:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[네트워크 장비]
    ↓
[서버 OS 작동]
    ↓
[애플리케이션 기능]
├─ 라우팅
├─ 필터링
└─ 패킷 처리

→ 패킷을 읽어야 하므로 OS 필요

네트워크 장비는 패킷을 읽어야하므로 내부에서는 서버 OS가 작동하며, 애플리케이션 기능으로 라우팅이나 필터링을 함

81. IDS / IPS

사이버 공격이 고도화되면서 기존 방화벽으로 막을 수 없는 공격도 등장하고 있음

필요성:
방화벽으로 패킷 입구를 강화하는 것뿐만 아니라 내부 네트워크 침입을 탐지하고 방지하는 시스템도 필요

부정한 패킷의 침입을 탐지하는 IDS와 IPS

방화벽의 한계:

보안 위협의 진화:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[과거]
  방화벽 → 입구 방어
    ↓
  효과적

[현재]
  공격 기술 고도화
    ↓
  입구만 강화해서는 부족
    ↓
  내부 탐지/방지 필요

방어 정책의 변화:

방화벽의 방어 정책은 입구의 방어벽을 높이고 검문을 강화하여 내부 안전을 확보하는 것. 그러나 공격자 수법이 고도화되면서 입구만 강화해서는 침입을 막을 수가 없음

IDS와 IPS 개념:

IDS vs IPS:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[IDS - Intrusion Detection System]
  └─ 침입 탐지 시스템
     └─ 패킷 침입 탐지
     └─ 경고 알림

[IPS - Intrusion Prevention System]
  └─ 침입 방지 시스템
     └─ 부정한 패킷 탐지
     └─ 자동 차단

탐지 방법:

방화벽의 스테이트풀형과 마찬가지로 다음 요소를 검증:

IP주소
포트 번호
프로토콜 순서
처리 상황

IDS와 IPS의 설치 유형

설치 장소에 따른 분류:

IDS/IPS 유형:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[호스트형 (Host-based)]
  └─ 서버에 소프트웨어 설치
     └─ 해당 서버의 패킷 검사
     └─ 로그 분석

[네트워크형 (Network-based)]
  └─ 네트워크 상에 설치
     └─ 흐르는 패킷 감시
     └─ 실시간 탐지

각 유형의 특징:

호스트형:
- 서버에 소프트웨어로 설치
- 부정한 패킷을 검사
네트워크형:
- 네트워크 상에서 흐르는 패킷을 감시

다양한 공격을 방어하는 시스템

차세대 방화벽 (NGFW):

차세대 방화벽 기능:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[NGFW - Next Generation Firewall]
    |
    ├─ IDS 기능
    ├─ IPS 기능
    ├─ 고기능 방화벽
    └─ 다양한 요소 검증
       ├─ 패킷 내용
       ├─ 프로토콜 순서
       ├─ 처리 상황
       └─ 앱별 패킷 동작

검증 요소:

IDS와 IPS, 고기능 방화벽은 차세대 방화벽이라고도 함(NGFW). 다음과 같은 다양한 요소로 검증:

패킷 내용
프로토콜 순서
처리 상황
앱별 패킷 동작
IP주소
포트 번호

기타 보안 시스템:

웹 보안 시스템:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[WAF - Web Application Firewall]
  └─ 웹 사이트 취약점 공격 방어
     ├─ SQL 인젝션
     ├─ XSS (Cross-Site Scripting)
     └─ CSRF

[UTM - Unified Threat Management]
  └─ 통합 위협 관리
     ├─ IDS
     ├─ 안티바이러스
     ├─ 로그 감시
     └─ 여러 기능 통합

CSRF 참고:

CSRF: Cross-Site Request Forgeries의 약어. 공격자가 방문자에게 위조된 URL을 열게 하여 표시된 웹 사이트에서 뭔가 조작을 하도록 하는 공격 기법

82. VPN/터널

VPN = Virtual Private Network

일반에 공개되어 불특정 다수와 연결되는 네트워크에 특정 상대만 이용할 수 있는 전용선을 가상으로 구축하는 기술

인터넷 등에 가상 전용선을 구축한다

VPN 개념:

VPN 동작 원리:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[호스트 A]
    ↓
[VPN 연결]
    ↓
암호화된 패킷
    ↓
[인터넷 (공개 네트워크)]
├─ 라우터 1 (내용 해독 불가)
├─ 라우터 2 (내용 해독 불가)
└─ 라우터 3 (내용 해독 불가)
    ↓
암호화된 패킷
    ↓
[VPN 연결]
    ↓
[호스트 B]

→ 가상 전용선 구축
→ 안전한 통신 경로

동작 방식:

호스트를 (일반적으로 라우터) VPN으로 연결하면 연결대상과 교환하는 패킷이 암호화됨
VPN 통신의 패킷은 다른 패킷과 마찬가지로 여러 라우터를 거쳐서 연결 대상까지 도달
중계하는 라우터는 패킷 내용을 해독할 수 없으므로 경로는 보호된 상태

캡슐화 (Encapsulation) - VPN의 핵심 기술

캡슐화란?

원본 패킷을 다른 패킷 안에 감싸서 전송하는 기술. 마치 택배 상자 안에 물건을 넣는 것과 같음

VPN 패킷 구조 - 겉포장과 내용물:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

┌─────────────────────────────────────┐
│  외부 IP 헤더 (평문 - 암호화 안 됨)   │  ← 라우터가 이걸 읽음
├─────────────────────────────────────┤
│  출발지: 192.168.1.100 (내 PC)      │
│  목적지: 1.2.3.4 (VPN 서버)         │
│  프로토콜: UDP/ESP                  │
└─────────────────────────────────────┘
         │
         └─→ 라우터: "1.2.3.4로 가야하네"

┌─────────────────────────────────────┐
│  🔒 암호화된 내부 패킷 (터널 내부)     │  ← 이 부분만 암호화
├─────────────────────────────────────┤
│  [암호화됨] 진짜 출발지: 10.0.0.5    │
│  [암호화됨] 진짜 목적지: 8.8.8.8     │
│  [암호화됨] 실제 데이터...           │
└─────────────────────────────────────┘
         │
         └─→ 라우터: "이건 해독 못 하겠네"

VPN 통신의 상세 과정

재택근무 시나리오 예시:

재택근무로 회사 서버에 접속하는 과정:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[집에서 직장 내부 서버 접속 시도]

1단계: 원본 패킷 생성
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[내 PC]
    ↓
┌──────────────────────────┐
│ IP 헤더:                  │
│   출발: 10.0.0.5 (내부IP) │
│   목적: 10.0.1.100 (회사) │
│ 데이터: 기밀문서 요청      │
└──────────────────────────┘


2단계: VPN 클라이언트가 암호화
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[VPN 소프트웨어]
    ↓
AES-256으로 암호화
    ↓
┌──────────────────────────┐
│ 🔒 암호화된 원본 패킷      │
│ [해독 불가능한 데이터]     │
└──────────────────────────┘


3단계: 외부 헤더로 감싸기 (캡슐화)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

┌──────────────────────────────────┐
│ 외부 IP 헤더 (평문):              │
│   출발: 192.168.1.100 (내 집 IP) │
│   목적: 1.2.3.4 (회사 VPN 서버)  │
│   프로토콜: IPsec/ESP            │
├──────────────────────────────────┤
│ 🔒 [암호화된 원본 패킷]           │
│    출발: 10.0.0.5 (암호화됨)     │
│    목적: 10.0.1.100 (암호화됨)   │
│    데이터: 기밀문서 (암호화됨)    │
└──────────────────────────────────┘


4단계: 인터넷으로 전송
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[라우터 1]
"외부 헤더를 보니 1.2.3.4로 가네"
"내부 내용은 암호화되어 못 읽겠네"
    ↓

[라우터 2]
"계속 1.2.3.4로 전달"
"내부 내용? 여전히 못 읽음"
    ↓

[라우터 3]
"1.2.3.4 도착!"
    ↓


5단계: VPN 서버 도착 및 복호화
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[회사 VPN 서버 1.2.3.4]
    ↓
외부 헤더 제거
    ↓
암호화 해제
    ↓
┌──────────────────────────┐
│ 원본 패킷 복원:           │
│   출발: 10.0.0.5         │
│   목적: 10.0.1.100       │
│   데이터: 기밀문서 요청   │
└──────────────────────────┘
    ↓
회사 내부 네트워크로 전달
    ↓
[회사 서버 10.0.1.100]

라우터가 보는 것 vs 못 보는 것

중간 라우터의 관점:

라우터의 시점:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[✓ 볼 수 있는 것 - 외부 헤더]
├─ 출발지 IP: 192.168.1.100 (내 집)
├─ 목적지 IP: 1.2.3.4 (회사 VPN)
├─ 프로토콜: IPsec/ESP
├─ 패킷 크기
└─ 전송 시간

→ "이 정보로 다음 라우터로 전달"


[✗ 볼 수 없는 것 - 암호화된 내부]
├─ 진짜 목적지: 10.0.1.100 (회사 서버)
├─ 실제 데이터 내용
├─ 어떤 파일을 요청하는지
├─ 어떤 서비스를 사용하는지
└─ 모든 내부 정보

→ "암호화되어 있어서 알 수 없음"

택배 상자 비유로 이해하기

VPN = 잠긴 금고를 택배로 보내기:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📦 택배 상자 (VPN 패킷)
│
├─ 겉 송장 (외부 헤더 - 평문)
│   ┌─────────────────────┐
│   │ 보내는 곳:           │
│   │ 서울시 강남구         │
│   │ (내 집)             │
│   │                     │
│   │ 받는 곳:            │
│   │ 서울시 종로구        │
│   │ (회사 VPN 서버)     │
│   └─────────────────────┘
│
│   → 택배기사(라우터)는 이것만 보고 배달
│
└─ 🔒 잠긴 금고 (암호화된 내부 패킷)
    ┌─────────────────────┐
    │ [잠긴 금고 내부]      │
    │                     │
    │ 내용물: 기밀문서     │
    │ 진짜 받는 사람:      │
    │ 3층 개발팀 김과장    │
    └─────────────────────┘

    → 택배기사는 금고 안을 볼 수 없음
    → 회사 도착 후 VPN 서버가 금고 열어서 전달

비유 요약:

실제 VPN	택배 비유
외부 IP 헤더	택배 송장 (누구나 읽을 수 있음)
암호화된 내부 패킷	잠긴 금고 (열쇠 없이는 못 봄)
라우터	택배기사 (송장만 보고 배달)
VPN 서버	회사 보안팀 (금고를 열 수 있음)

터널 (Tunnel)

터널 기술:

터널링 개념:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[원본 프로토콜 패킷]
    ↓
[다른 프로토콜로 캡슐화]
    ↓
[터널 (보호된 경로)]
    ↓
[원본 프로토콜로 복원]

→ 프로토콜 패킷을 그대로
   다른 프로토콜에 실어 전송

용어 정의:

터널이라는 용어는 본래 프로토콜의 패킷을 그대로 다른 프로토콜의 패킷에 실어 전송하는 기술을 가리키며, 경로 암호화는 필수 요소가 아님

활용 목적:

경로 내에 다른 프로토콜의 네트워크가 있을 때는 패킷을 원활하게 전달할 수 있는 터널을 사용하는 것이 유용함. 이런 처리를 캡슐화라고도 함

VPN의 보안 효과

보안 이점:

VPN 보안 효과:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[기밀성 보호]
  ✓ ISP(인터넷 서비스 제공자)가 내용 볼 수 없음
  ✓ 중간 라우터가 목적지 알 수 없음
  ✓ 공용 Wi-Fi에서도 안전

[위치 은폐]
  ✓ 실제 IP 주소 숨김
  ✓ VPN 서버 IP만 노출

[방화벽 우회]
  ✓ 차단된 사이트 접속 가능
  ✓ 지역 제한 우회

공용 Wi-Fi에서 VPN의 중요성:

공용 Wi-Fi 위험:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[VPN 없이]
  카페 Wi-Fi → [평문 데이터] → 인터넷
                   ↑
              [공격자가 도청]

[VPN 사용 시]
  카페 Wi-Fi → [암호화 데이터] → VPN 서버 → 인터넷
                   ↑
              [공격자가 못 봄]

암호화와 터널을 구현하는 VPN 프로토콜

주요 VPN 프로토콜:

VPN 프로토콜 종류:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[IPsec]
├─ 인증 기능
├─ 패킷 암호화
└─ 인터넷 표준

[L2TP - Layer 2 Tunneling Protocol]
├─ 터널만 제공
└─ 암호화 없음

[PPTP - Point-to-Point Tunneling Protocol]
├─ 윈도우 표준
└─ 레거시 프로토콜

[SSL-VPN]
├─ SSL/TLS 사용
├─ HTTPS 기반
└─ 웹 브라우저 연결

각 프로토콜 특징:

프로토콜	암호화	터널	특징
IPsec	O	O	인증 + 암호화, 인터넷 표준
L2TP	X	O	터널만 제공, 전용 경로 구축
PPTP	O	O	윈도우 표준 (레거시)
SSL-VPN	O	O	HTTPS 사용, 브라우저 지원

프로토콜별 상세:

IPsec: 연결 대상의 인증 기능과 패킷의 암호화 기능을 갖춘 프로토콜로, 인터넷 표준
L2TP: 패킷 암호화는 하지 않고 터널로 연결 대상과 전용 경로를 구축하는 프로토콜
PPTP: 윈도우에서 표준으로 사용되던 프로토콜
SSL-VPN: SSL을 사용하므로 웹 브라우저 연결을 VPN으로 사용하고자 할 때 이용. HTTPS를 사용해서 암호화와 터널을 구현

83. 트래픽 감시/로그 감시

네트워크를 안전하게 보호하는 데 액세스 제어 및 통신 암호화뿐만 아니라 트래픽 및 로그 감시도 중요

최근 동향:
AI를 이용하여 감시를 자동화하기도 함

이상 검출을 위한 트래픽이나 로그 감시

감시의 중요성:

보안 감시 필요성:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[네트워크 상태 파악]
    ↓
평소 상태를 알아야
이상 징후 감지 가능
    ↓

문제 유형:
├─ 이전부터 지속된 문제?
└─ 갑작스런 발생?

→ 지속적 감시 필요

보안을 높은 수준으로 유지하려면:

네트워크 상태를 항상 감시하고 검증하는 것이 중요. 네트워크 상태를 늘 파악해 두지 않으면 이상이 발생해도 이전부터 지속되던 문제인지, 갑작스럽게 발생한 문제인지 알 수 없음

공격 기술의 다양화:

다양한 공격 기법:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[취약성 공격]
└─ 서버/앱 취약점 이용

[비정상 프로그램]
└─ 정상처럼 보이는 침입

[계정 탈취]
└─ 정상 사용자로 위장
   └─ 정상 로그인
   └─ 비정상 작업

→ 탐지가 어려워짐

서버나 앱 등 취약성 공격, 비정상적인 프로그램을 사용하는 침입, 정상 사용자로 위장하는 침입 등 공격 기술도 다양해지고 있음. 해킹된 계정을 이용해서 정상적으로 로그인하면 비정상적인 작업을 탐지하기가 어려워짐

트래픽 감시

감시 대상:

트래픽 감시 항목:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

네트워크에서 수상한 동작 검출:

[트래픽 감시]
    ↓
확인 항목:
├─ 평소 없는 해외 접속
├─ 비정상적 통신 패턴
├─ 대량 데이터 전송
├─ 알 수 없는 포트 통신
└─ 이상 프로토콜 사용

네트워크에서 수상한 동작을 검출하려면 네트워크 트래픽을 감시해야 함. 예를 들어 평소 발생하지 않는 해외접속이나 통신 등이 있는지 확인함

로그 감시

감시 대상:

로그 감시 항목:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

서버 이벤트 로그 확인:

[로그 감시]
    ↓
확인 항목:
├─ 수상한 통신
├─ 중요 데이터 액세스
├─ 로그인 오류
├─ 권한 변경
├─ 시스템 설정 변경
└─ 파일 무단 접근

서버의 이벤트 로그를 확인하여 수상한 통신, 중요 데이터에 대한 액세스나 로그인 오류 등이 있는지 확인함

트래픽 감시와 로그 감시 방법

트래픽 감시 도구:

트래픽 감시 방법:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[차세대 방화벽]
    ↓
고기능 제품 활용
    ↓

[패킷 캡처 기능]
    ↓
네트워크 기기 활용
    ↓

[실시간 체크]
    ↓
패킷 상시 감시
    ↓

[거의 실시간 탐지]

트래픽 감시는 차세대 방화벽과 같은 고기능인 제품이나 패킷 캡쳐 기능이 있는 네트워크 기기를 이용함. 이런 장비의 기능을 이용하면 네트워크를 흐르는 패킷을 상시 체크할 수 있으므로 거의 실시간으로 이상을 탐지할 수 있음

로그 감시 방법:

로그 감시 방법:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[서버 로그 파일]
    ↓
[소프트웨어로 해석]
    ↓
[공격/이상 흔적 체크]
    ↓
[과거 발생 상황 조사]

특징:
• 사후 분석
• 흔적 추적
• 패턴 분석

로그 감시는 서버의 로그 파일을 소프트웨어로 해석함. 로그 파일에 남아있는 공격이나 이상 등 흔적을 체크하여 이상이 발생하지 않았는지 조사함. 로그 감시는 과거 발생 상황을 조사하게 됨

감시 시스템 비교

구분	트래픽 감시	로그 감시
시점	실시간	사후 분석
도구	차세대 방화벽, 패킷 캡처	로그 분석 소프트웨어
감시 대상	네트워크 패킷	서버 로그 파일
탐지 속도	거의 실시간	과거 흔적 추적
활용	즉각 대응	원인 분석, 패턴 파악

통합 보안 전략:

효과적인 보안 감시:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[트래픽 감시]
    +
[로그 감시]
    ↓
[종합 분석]
    ↓
[보안 위협 대응]

→ 실시간 탐지 + 사후 분석
→ 완전한 보안 체계